为什么测试对云原生流水线不再足够
作者：Alex Zhitnitsky。最初在OverOps博客上发表。
https://blog.overops.com/why-testing-is-no-longer-sufficient-for-todays-software-delivery-pipelines/
以速度和规模进行创新的举动让软件质量变得紧张，暴露了测试的局限性。
不要误解我——所有形式的测试都与软件交付供应链密不可分。测试和静态分析对于软件开发流水线是必不可少的，这对于传统和云原生应用程序都是如此。
但问题是，它们是不够的。
我们正处在一个前所未有的时代，一个颠覆性的时代，历史悠久的金融机构正面临着来自7年之久的初创企业的竞争。企业面临着快速行动以保持生存的压力，即便是那些已经存在了100多年的企业，它们也需要以两倍的速度行动，以捍卫自己的地位并保持竞争力。
十多年前，当引入测试驱动开发（TDD）时，它承诺提高生产力和质量。即使是那些不太关注它的团队，也会注意它。从那以后，发布周期缩短了，CI/CD不再是一个时髦的词，而开发流水线自动化产品的新公司——我在看你们，GitLab——已经足够成熟，可以上市了。
重申这一点，测试可能比以往任何时候都更相关，但是当快速移动是表利害关系时，仅仅依靠传统测试来防止错误是不够的。尽管测试是不可替代的，但关键的错误仍然会出现在生产中，而客户正在等待他们承诺的无缝体验（就在他们的应用程序中断之前）。
底线？测试已经不够了。在这篇文章中，我们将概述我们是如何到这一点，以及专家们对此有什么看法。
红皇后假说（以及它对测试的意义）
在数字商业的背景下，停滞不前等同于失败。Lewis Carroll在《爱丽丝梦游仙境》（Alice in Wonderland）中说得最好，这成为“红皇后假说”（Red Queen Hypothesis）的基础：
《红皇后假说》不仅是一本伟大著作中的奇闻轶事，它还源于一个进化的概念，即生物必须不断适应才能生存，同时还要在不断变化的环境中与其他生物竞争。
同样的思想也可以应用到业务环境中，这说明了为什么每个公司都急于将自己的CI/CD工作流自动化。这里的二阶效应是它如何应用于测试的。当你越来越快地发布代码，提高开发速度时，如何防止错误升级？如果它们真的发生了，你怎样才能快速修复它们？
时速70英里的公路汽车的安全措施与时速200英里以上的F1汽车的安全措施非常不同，因此当你将CI/CD工作流程自动化时，测试也需要改进。
专家们对此有什么看法？
根据谷歌云的DevOps Research & Analysis（DORA）DevOps状态报告，更改故障率（即导致服务降级并需要修复的生产更改的百分比）可以达到所有新代码发布的60%。对于优秀的执行者，失败率可以保持在15%以下，但是由于这只针对已知的错误，并且是基于工程师（而不是客户）的自我报告，实际的失败率甚至可能更高。
https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
低绩效者和优秀绩效者之间的差距相当大，这使得精英在创新和快速行动的能力上拥有“不公平的优势”。这解释了我们从Facebook、苹果、Netflix、微软和谷歌等大型科技公司那里看到的结果，尽管它们也不是没有错误。
这背后的一个关键驱动力是能够以更高的频率发布更小的变化——但这并不是唯一的区别。虽然所有的公司都在以这样或那样的形式进行测试，但是它们如何进行测试以及它们寻找的是什么却有很大的不同。
在最近的一次现场讨论会上，我们与DevOps Paradox的共同主持Darin Pope讨论了这个问题，他是DevOps的顾问，以使复杂变得简单而闻名，还有Viktor Fracic，他是总软件交付战略家、开发人员倡导者和出版作者。与OverOps解决方案工程副总裁Eric Mizell一起。
按需录制的对话回放，包括通过持续可靠性（Continuous Reliability）平衡速度和质量的要点，可在这里获得。
https://land.overops.com/the_devops_paradox/
下面是对话中的三个要点，说明了为什么传统测试是不够的：
1. 100%的代码覆盖率≠100%的错误识别
Viktor Fracic：“代码覆盖毫无意义。我不明白为什么人们仍然痴迷于代码覆盖。问题不在于你有多少测试，而在于这些测试的质量。我见过一些公司，他们的代码覆盖率接近100%，但是他们的测试毫无意义，什么也证明不了。”
“在我看来，这些指标非常具有误导性。拥有95%的测试代码覆盖率很容易，但是拥有真正重要的测试，让它们驱动你的设计，并检测那些难以检测的东西，这才是真正困难的。如果测试本身做得不是很好，那么代码覆盖就没有多大用处。”
2. 高质量的测试需要时间，但不能保证成功
Darin Pope：“这是大多数人的日常生活，我宁愿在生产中发生错误并迅速进入市场，也不愿在失去所有市场机会的情况下花5年时间来开发产品。我宁愿看到人们快速行动，坦然面对失败。”
Viktor Fracic：“如果你开发了五年，然后投入生产，它仍然会失败。在将其投入生产之前，你并不真正知道它在实际用户中的表现。我们只是想在投入生产前尽可能地保持稳定，但一旦稳定了，我们就能知道发生了什么，并迅速做出反应来解决问题。但是你会测试，测试，测试然后你说，是的，现在它会100%工作，这从来没有发生过。如果你能帮我找到一个有这样才能的人，我很高兴能见到他们。”
Eric Mizell：“我不想生产力下降，然后惨败。但是我确实希望能够有合适的人员和流程来修复它，因为你希望采用快速行动/快速修复的心态。我想要更快地实现它，因为在当今世界，我需要更快地行动。在云计算的世界里，一家新公司可以花一天的时间，与我竞争我已经工作了五年的东西。我需要弄清楚如何快速前进，如何在不摔倒的情况下继续前进。”
3. GA实际上是一个测试版，而用户是新的QA
Viktor Fracic：“我想说，这在很久以前是真的。只是现在我们承认了。每个人都知道，我们从来没有在生产中部署稳定的代码，从来没有失败或没有任何问题。20年前，世界上的每一家公司都收到用户的通知，这个或那个不工作，然后你需要修复它。我们知道这一切，现在我们只是承认现实。”
Eric Mizell：“我曾听一家公司说，他们试图对失去客户和收入与推出软件的风险程度进行风险评估。他们需要新的特性。这是一个平衡。我不认为任何人有完美的平衡，但你看到它发生了很多，它回到我想要能够快速移动/快速修复的概念。如何从失败中走出来才是真正的挑战。”
总结
作为开发人员，我们非常擅长编写代码，但在预测代码将在何处崩溃方面存在固有的能力限制。如果我们想要实现快速移动/修复快速视图，那么检测软件问题的任务，无论是在测试的早期还是在生产的后期，以及收集有关软件问题的信息都应该是自动化的。
点击【阅读原文】阅读英文原文。
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。